CD ROM Paradise Collection 4/CD ROM Paradise Collection 4 1995 Nov.iso/bbs/jdrexa10.zip/INST4OF4.DAT/BBS/HELP/NET_MAIL.DOC

Text File | 1994-12-18 | 48KB | 1,012 lines

                         Using Net Mail with Juggernaut


    OVERVIEW

    Juggernaut includes complete Fido-style Net Mail capabilties.

    It is a Mailer.  A mailer dials up other BBS's to exchange mail, and
    accepts inbound (incoming) mail from other BBS's.

    It is a Tosser.  A tosser imports mail bundles to your BBS, and extends
    mail bundles for other BSS's (if you are a Hub/Host).

    It is a Scanner/Packer.  A scanner/packer creates outbound bundles of
    mail for other BBS's.  Usually from your own mail areas.

    It supports NetMail.  NetMail is private or public directly-addressed
    mail to another person on another BBS.

    It supports EchoMail.  EchohMail is a public message area whose mail
    goes to every BBS subscribing (connected with) that particular message
    area.

    It supports FREQ's.  FREQ's are File Requests that you can make to other
    BBS's directly to get some file(s) they have made available just for
    FREQ'ing (using the Net Mail system rather than the hassle of calling up
    and logging on).  Similarly, Juggernaut supports you defining FREQ'able
    files that other sysops may download.

    Juggernaut also does some other things: the ability to configure
    individual net addresses for a variety of things, the ability to send
    out all the non-Net mail for a given individual along with their normal
    net mail, merging multiple EchoMail mail areas into a single BBS mail
    area, the ability to handle multiple zones and nodelists, simple
    forwarding of mail, Hub/Host management of mail, multiple nodelist
    management, FREQ'able functions, zone matching and flexible addressing,
    alias support, auto-backup of inbound packets, and agressive duplicate
    message handling.

    The Juggernaut net mail system is, for the most part, invisible to
    callers.  It is able to accept mail at the logo and login-name without
    having to display what is known as the "<esc><esc> mailer screen".
    Similarly, when displaying net messages, all the "kludge", and other
    net-attached, lines to messages can be made hidden.


    FIDO-STYLE NETWORKS

    What is a Fido-style network, and how does it operate?

    Fido itself takes its name from the BBS program of the same name that
    started the Fido-sytle format.  It is still used today, and is known as
    FidoNet.  FidoNet is the largest of the Fido-style networks (by far) and
    pretty much sets the rules and standards for all smaller networks that
    use its standards.

    Most likely, the only Fido-style network you will join is FidoNet.  To
    that end, I will explain things in terms of how FidoNet operates.
    However, you should feel free to extrapolate what I say to all networks.

    The first thing to know about these networks is that each BBS is given a
    unique network address.  These addresses are of the form
    "Zone:Net/Node".

    All the BBS's joined to a network appear in that network's nodelist.  At
    last check, FidoNet's nodelist was about 2.5 megs and growing.

    Zone is used by FidoNet to designate geographical regions.  "1" is all
    of North America, "2" is all of Europe, etc.  FidoNet, however, uses
    only a few of the zone numbers.  The remaining zones are usually used to
    designate other networks.  Usually, "another network" = "another
    nodelist" = "its own zone number".  That is, different networks, can be
    thought of as different nodelists (since they do have different
    nodelists), which use different zones.  It's a way to keep networks
    separate from each other.

    The Net number in the address is sub-network.  Usually it has a central
    Host node, through which all mail to/from addresses in that Net number
    use.

    The Node number is the unique number, in your Net, that separates one
    BBS from another.

    Hub nodes are Host helper nodes.  They usually do the same things Host
    nodes do, but exist to distribute the Host's workload.

    The Host is the key to all of FidoNet.

    FidoNet is a global network.  It allows any BBS to cheaply send mail to
    any other BBS in the network (in the world).  It does this by
    maintaining a 3-tiered structure: Regional Hosts, Net Hosts, normal
    nodes.

    Regional Hosts are just Hosts, except they only send and receive mail
    between other Hosts, and Net Hosts under their control.  Regisonal Hosts
    are responsible for, well, regions.  "The US Midwest", "France",
    "Southern California"--the size of the geographical region they control
    depends on the amount of mail traffic and nodes, you want balanced
    regions.

    Dropping down to the next level, we have Net Hosts.  Just like Regional
    Hosts divide up the world, Net Hosts divide up regions.  Same principle
    of dispersion as regions--balancing out the nets--but usually more of a
    factor is long distance--you want a Host in each area code.

    A Host/Hub is just another node like yourself, but bigger. Net Hosts
    exchange mail with the member nodes under their control, and their
    Regional Host.  Normally, a Net Host only makes a single long distance
    call (each night) to it's Regional Host to exchange mail.  Since all
    nodes it controls are usually local calls, there is little or no cost to
    maintain the local network.

    The Nodes are individual BBS's.  Depending on how the local network is
    setup, usually these nodes will Poll (call up and pickup/dropoff mail)
    their local Host/Hub each night, or the Host/Hub will Poll them each
    night.

    It is the simple hub-and-spoke system.  Airlines and shipping companies
    use this method as well.  It is quite common, and very efficient.

    You must be a FidoNet member to use FidoNet Host/Hubs, and the messages
    you route through the Host/Hub must be destined for other FidoNet
    members.  These other members can be local addresses or long distance or
    even international.  The same is true for each other network.

    The whole system usually works as follows:  You or your users post a
    message on your BBS in an EchoMail or NetMail area.  In the dark of
    night, your BBS poll's your Host/Hub, dropping off this new net mail
    message and any others, and picking up any that are for your BBS.  At
    some point in the night, the Host/Hub BBS calls it's Regional
    Coordinator (Regional Host) and drops off mail to addresses outside
    those it controls, and picks up mail to addresses it controls.  Late
    that night, the Regional Coordinator distributes mail meant for other
    regions to other Regional Coordinator BBS's.  Who, the next night or
    days later, eventually just reverse the process and that message ends up
    at the BBS it was destined for.  Or, if EchoMail, all the BBS's
    subscribing to that Echo.

    Typically your local Host/Hub will extort (request) that you give
    (contribute) some money towards paying his long distance costs for
    calling up the Regional Host (Regional Coordinator) each night.  Usually
    it's small, $25 per year or so, and the local Host/Hub determines what
    to do if you don't pay (contribute).  Options (punishments) include
    denial to FidoNet, denial of just EchoMail areas.  Local Host/Hub's can
    sometimes be little dictatorships, demanding unreasonable information or
    dollars to access FidoNet.

    To join FidoNet, call up a local BBS in your area that carries it, and
    ask the sysop who to call.  Usually it will be the Host of your area.
    He will make you jump through hoops, but eventually give you a FidoNet
    address and various files on using FidoNet.  It also gives you access to
    at least 500 EchoMail areas, on all topics, from which you may select to
    receive--and will receive pretty much immediately.


    JUGGERNAUT SETUP

    There are 3 parts to Net Mail setup on Juggernaut: Message Areas, Sysop
    Commands, and Menu Commands/Events.


    SETUP: Message Areas

    To first use NetMail and EchoMail on the BBS, you must create some areas
    to put the mail into.  If no areas exist, the messages are dumped into
    Private Mail.

    This process involves merely changing the Message Area Attributes for
    each message area.

    The important Attributes are:

      3  which, when ON, tells the software that this is to be a net mail
         area.
      9  which, when ON, tells the software that is to be an EchoMail area.

      When 3 and 9 are both OFF, or when 3 is OFF and 9 is ON, the message
      area is not a net mail area.

      When 3 is ON and 9 is OFF, the message area is a NetMail area.

      When 3 is ON and 9 is ON, the message area is an EchoMail area.

      You can define a message area as an EchoMail area if you want to allow
      non-user names in a local message area.  I found this useful for door
      mail--where users can send mail to the pseudoynms the players were
      using.  As long as you do not route it out (see below) its messages
      won't go anywhere.

    The difference between NetMail and EchoMail isn't that much.  NetMail is
    single bullet aimed at another person, EchoMail is a shotgun aimed at
    other BBS's (and those interested in that message area on those BBS's).
    NetMail is individual mail, EchoMail is message area mail.  Private
    NetMail is just Private Mail between BBS's.

    For NetMail, you must always specify a person.  For EchoMail, you can be
    less specific: ALL, Everyone, Fellow Sentient Beings, etc. since no one
    person receives the message.

    EchoMail can only be Public areas.  Although you can specify it as
    Private or give it a high SL to hide it from your users.  On another BBS
    it may be open to those same users--and all messages posted in an
    EchoMail area are sent to all those other subscribing BBS's.

    NetMail may be either Public or Private--although most sysops just set
    up one Private NetMail area.  At most you can only have two areas:
    Public NetMail and Private NetMail.

    Other Message Area Attributes that relate to net mail:

      7  Usually OFF.  When ON, everyone is able to see the kludge and net-
         stuff lines normally hidden within the message.  They lose their
         interest pretty fast and just clutter up the actual message.
      8  Usually ON.  When ON, when messages in this area are successfully
         sent ([Sent]) they are deleted automatically.  This does not work
         if the area is an EchoMail area, and only works with normal areas
         (those without Attibute 3 ON) when non-net mail giving was invoked
         (see below).  Individual message attributes also effect this (see
         immediately below).
      A  When ON, EchoMail messages produced on your BBS have an "Origin"
         line you specify attached to them.  This is usually a line
         describing your BBS (see SHORT.TXT where the line is located, and
         the numerous Origin lines you will see in incoming messages).  It
         is not required and is generally thought as wasteful self-
         promotion.  Still, most sysops like to use them.
      B  Usually OFF.  This controls whether the FROM: field should always
         use the users real name.  Their real name being stored in the
         SysopNote field (there is a Toggle which controls this).  Some
         EchoMail areas demand only real names, and if your BBS supports
         handles you will either have to drop the echos that disallow
         handles, or require your users to provide their real names.

    Individual messages have the following net-related attributes:

      Attibutes:

      4  When ON: when message is [Sent] and it's a net mail area, or when
         the message is read and it's a non-net mail area (for non-net mail
         giving usually, but AI messages also use) then we delete the
         message.
      5  When ON, the message cannot be auto-deleted (cancels the effects of
         4 above, and Message Area Attribute 8).
      E  When ON, the message is Sent.  When reading messages, this appears
         as a little "[Sent]" displayed with the date line.  Turning this
         OFF will usually mean the message will be again sent out.  This
         only matters for NetMail, as EchoMail relies on Last-Read pointers
         for subscribing net addresses (usually your Hub, see below).
         However, even though it matters only for NetMail, when I refer to
         "deleting when [Sent]" I mean both when NetMail and EchoMail
         messages are sent.

      Attributes2:

      1  Usually OFF.  When ON, it tells the software to wait until you are
         in contact with the addressee's address before giving them the
         message.  Known as Direct mail exchange (no Hub/Host's).  Only
         matters for NetMail.
      2  Usually OFF.  When ON, the message is not to be net mailed out.
         Useful for stopping EchoMail messages from being sent out.


    SETUP: Sysop Commands

    From sysop menu: Global: Net Mail yields:

      Network Configuration
        Node Lists
        Zones & Your Address(es)
        Passwords & Attributes
      EchoMail Configuration
        EchoMail AREA Mapper
        EchoMail Routing
      Extras
        FREQ'able Files
        Multiple File Attaching
        Destination Forwarding
        Non-NET Message Giving
        NameTags
      Other
        Import A Loose Fido PKT
        Import An AREAS.BBS File

    It is pretty much in the order of concern for setting up net mail.  With
    the exception of the last two, they are all databases.

    Network Cofiguration options tell the software your place in the various
    networks.

    EchoMail Configuration options tell the software how EchoMail message
    areas are to be handled.

    Extas are personal stuff you set up for others (FREQ's) or for specific
    individuals (including yourself).

    Other is just the option of importing a fido packet that for some reason
    hadn't gotten imported in the normal course of operations, and to import
    an AREAS.BBS which only Hub-type people might want to do once.


    Node Lists

    Node lists are the phone books of the Fido-style networks.  This
    database tells the software which networks you have joined.

    After you have contacted your local Host/Hub, one of the things they
    will tell you to do is get the latest nodelist.

    The "Node Lists Database" contains the pathnames of your network node
    lists.  It contains only one important data field: that of the pathname
    to the nodelist.

    These nodelists are standard text files.  You have one for each network
    (zone).  If you set up your own small network(s), you need to create a
    nodelist for each.  I've enclosed JDR_BBS.NET as a template for starting
    your own network.

    Your nodelists should remain in their standard text format.  Juggernaut
    will make its own index from it, so other node list indexing programs
    are useless.

    Using a wildcard for the pathname is useful.  The software will
    automatically update the index when it finds a new nodelist file.

    Updating nodelists for FidoNet means getting a NODEDIFF file from your
    Host/Hub each week, and running an update program to merge the NODEDIFF
    update file with your current nodelist file.  The software automatically
    detects changes in the nodelist files and will update them the next time
    the BBS is restarted.

    Smaller networks usually just give you a whole new nodelist when they
    update, and do not necessarily do it each week.


    Zones & Your Address(es)

    Remeber that the network(s) you join will each have a unique zone.
    Some, like FidoNet, will use multiple zones.  Within each of these
    networks that yo are a member of, you will be given an address.

    This database organizes your addresses.  It tells the software how you
    relate to the networks.  It also organizes who your Host is.  If a
    normal node, it's your Host/Hub address.  If you are a Host/Hub it's
    your Regional Host's address.

    There are only two fields that matter in this database: Your Address,
    and Your Host/Hub's Address.  The other fields (including the one
    labeled AKA's, are not yet finished).

    For each network you are a member of, you should put your address here,
    and right next to it, the address of your Host/Hub (or 0:0/0 for none).

    If you have multiple addresses for a network (AKA's or Alias's), you
    should specify them on their own line, and use 0:0/0 for the Host/Hub.

    The order you enter all your addresses (although normally you will have
    just one) is important.  The very first address in the database is the
    one from which "filling" is done.  When a user enters a shorted address,
    the remainder of it (zone and/or net) is filled in with whatever's in
    the first entry.  Example: if your address is "1:100/20" and a user
    enters "30" as the "At" address, it fills it in to form "1:100/30" as
    the destination address.

    The importance of order also extends to Alias/AKA addresses.  Addresses
    are considered to be Alias/AKA if they share a common zone.  Only for
    the first one with that zone, however, does the Host/Hub field matter.

    Example:

      1:100/20   1:100/0
      10:154/2   10:154/0
      10:154/40  0:0/0

      This tells the software that you have one address for zone 1
      (1:100/20), and 2 addresses for zone 10 (10:154/2, 10:154/40).  That
      your Host/Hub for zone 1 is 1:100/0, and that your Host/Hub for zone
      10 is 10:154/0.

    When the software does exchanging of mail, it presents all addresses
    (normal and alias) to the other computer.

    When it comes to import mail bundles, the software will look for
    messages addressed to all addresses (normal and alias) that you have
    defined as your's.

    A Host/Hub entry is not required, and if you do not route your mail to a
    higher authority, you need not put anything here.  However, before going
    too independent, remember that the Host/Hub system does offer huge cost
    savings.

    Another thing these extra (alias) entries allow you to do is stop
    outgoing mail to particular addresses.  The software filters all
    outgoing messages, and will not send any that are destined for your
    addresses (normal and alias). This trick, however, cannot be used for
    addresses within your Net area--then you will be getting that BBS's net
    mail from your Host/Hub, making two sysops mad--and possibly not used at
    all if your Host/Hub decides they don't want you doing it.


    Passwords & Attributes

    This database tells the software how you wish to interact with other
    nodes in the network.

    The "Passwords & Attributes Database" contains information on the limits
    of other net addresses you exchange mail with--be they Host/Hubs or not.

    Entries in this database are for those addresses you exchange mail with
    directly.  That's the Host/Hub address, and anybody you exchange mail
    with who you do not route your mail via the Host/Hub through.

    The fields in this database define such things as the session-level
    password to use, what type of packet compression (if any) that node
    prefers, and whether you allow this node to FREQ files from you.

    Example, your Host/Hub might have a password he wants you to use--you
    would put the Host/Hub's net address and his password in this database.

    Example: your Host/Hub at 1:100/20 would also have the "exclude file
    attaches" attribute ON, because you can't route file attaches via
    Host/Hub's.  But it would not have the "route directly" attribute ON--
    because you route it's mail via the Host/Hub (even though it is the
    Host/Hub).

    Example: you have a Host/Hub at 1:100/20 for zone 1.  But for zone 50,
    you have no Host/Hub.  You exchange mail with two addresses in zone 50:
    50:200/30 and 50:154/40.  50:200/30 wants only LZH compressed packets.
    How many entries do you need here?  Answer: One.  You need to specify
    that 50:200/30 wants their packets compressed in LZH format.  50:154/40
    has no special requirements, so does not need an entry.  Because your
    Host/Hub at 1:100/20 is ONLY for zone 1, he's not going to get any mail
    to route to zone 50 (he has nothing to do with zone 50).

    Example: you have a Host/Hub at 1:100/20 for zone 1.  You exchange mail
    each night with him, and another node (1:100/42) which you also exchange
    mail each night.  However, the Host/Hub gets mail to route, but the
    1:100/42 guy is just getting his own mail.  What entries do you need?
    You'll need the usually Host/Hub entry for 1:100/20.  You will also need
    an entry for 1:100/42--with the attribute "route directly" ON.  This
    attribute tells the software to NOT send any mail to that address via
    the Host/Hub.  The only reason to not route the mail via the Host/Hub is
    because 1:100/42 does not want it that way.

    This database also has fields for NET-DIR stuff--which will be
    implemented next release.  Ignore them for now.


    EchoMail AREA Mapper

    The "EchoMail AREA Mapper Database" tells the software how to handle
    incoming messages.

    With each message area you sign up for, you will be given a Tag/AREA
    name/title.  This is the message area's identifier--unique to that one
    EchoMail area on the network.

    What the software needs to know is which of your message areas you want
    these messages to go (and you can have multiple incoming AREA's go to a
    single of your message areas--for outgoing messages, it uses the first
    one defined for that area).

    For example, you want the FidoNet Echo "SF Stories".  You tell your
    Host/Hub (or Echo Coordinator) you want this Echo.  He tells you that
    this Echo has the Tag name "SF_STORIES".  You create a message area,
    give it the title "SciFi Stories, Ideas, and Comments" (say, area #10).
    Then you go to this database, and type in the message area number, for
    "SciFi Stories..." which was #10, and the Tag name, "SF_STORIES".
    That's it.


    EchoMail Routing

    The "EchoMail Routing Database" tells the software which net addresses
    get the messages in your EchoMail message areas.

    You must specify each address who is to receive messages.

    For most people, this means using your Host/Hub's address with each of
    your EchoMail areas, and Attribute 1 ON.

    Attribute 1 ON tells the software only to send messages your BBS
    created.  When OFF, it will send all messages.  This is known as "being
    fed", and "feeding".  A Host/Hub is feeding you the Echo--so all you
    want to do is give him stuff he does not already have (your messages).
    But there may be times when you are the one doing the feeding--then you
    want to send to a BBS all the messages.

    For each entry, there is a Last-Read value.  This works just like user
    Last-Read pointers.  The net address will only get those messages new
    since these Last-Read values.

    EchoMail, message numbers only matter on your BBS--there is no message
    number matching between the BBS that sent the message, and all the BBS's
    that receive it.  So when you start a new Echo, all message numbers
    start at one, even though it may be the 150 thousandth message ever
    posted in that echo.


    FREQ'able Files

    The "FREQ'able Files Database" tells the software what files other
    sysops (using Net Mail) can FREQ, or File Request, off your BBS.

    There are two things that define a FREQ'able file: the file's pathname
    and it's Magic name.

    The Magic name is the name the person requesting the file uses when they
    want your file.  The magic name works just like DOS's "SET" (eg. SET
    DSZLOG=C:\BBS\DSZLOG), in which you're defining a shorter name to
    represent something long.

    For example, if you wanted to make the latest FidoNet nodelist a FREQ on
    your BBS, you would create an entry like "nodelist" for magic name, and
    "c:\bbs\dnloads1\fido*.*".

    You can define multiple pathnames and magic names that access the same
    files--the software properly handles situations when multiple copies of
    the same file would be sent, and sends only one.

    An incoming FREQ is checked against both your magic name, and your
    pathname (filename part of the pathname), and if a match is found the
    pathname is sent.

    If you specify Attribute 2 as ON, the software will interpret the
    pathname field as a shell-to-dos order.  The software will execute
    pathname as so:

      pathname <port> <pathname to netnode.flo>

      The "<port>" is the communications port, but really not too useful.
      The "<pathname>" provides the location of the outbound .FLO file.
      This .FLO file contains a list of pathnames to send to the other BBS.

    This allows you to create batch files which can be run to do stuff.

    Example, a FREQ'able function's batch file might look like so:

      pkzip test master.lst
      echo c:\bbs\test.zip  >> %2

      This ZIP's up your MASTER.LST file into TEST.ZIP.
      It then attaches the pathname of this TEST.ZIP file to the end of the
      .FLO file.
      When it exits this batch file, the BBS will continue its net mail
      session as normal, which involves sending everything in the .FLO file
      to the other BBS.
      Thus, you have it, a FREQ'able function: to give a list of all files
      you have on-line to BBS's with the right magic name.

    If you want to FREQ a file off another BBS, you can do it via the "Do A
    Freq" command when Entering Messages.

    It is common practice for a BBS to set up a special magic name, FILES,
    which contains a list and descriptions (and magic names) of all the
    files other sysops are able to FREQ off your BBS.  To do this, you would
    just edit a FILES.TXT file, create an entry here with "Magic Name =
    FILES" and "Pathname = d:\etc.\FILES.TXT".

    FREQ's can (and are) only processed by calling BBS's directly.  The
    requests are not sent through Host/Hub's, and requested files are not
    sent through Host/Hub's.  The main reason being the cost, but a
    secondary reason being that they are extremely difficult to keep track
    of--particularly when there is more than one destination getting the
    same file.


    Multiple File Attaching

    This command lets you send multiple files to another net address,
    or a single file to multiple net addressess, or multiple files to
    multiple addresses.

    It is a more powerful version of the "New FAs" you can do when
    entering a message.

    The files are sent whenever we next contact that address.

    This command has pretty good on-line docs, so you should read them
    over if you frequently send net file attaches.


    Destination Forwarding

    Destination forwarding is trick.  It allows you to route all incoming
    messages to another net address.

    In the normal net mail world, it is not much use.

    Where it is useful is as the "call forwarding" of your NetMail.

    When an incoming message is both to the specified address, and to the
    specified person, it is simply marked un[Sent] and given a new net
    address.  It must be a net address outside your networks realm, or the
    Host/Hub will pick it up again and resend it.

    For instance, you are node 1:100/30 and exchange mail with your Host/Hub
    at 1:100/20.  But you have a computer at work, and you get bored there
    easily.  You set up the work computer to be a BBS at night--doesn't
    matter what type of BBS, maybe you use it to Poll other long distance
    BBS's.  You create a personal network between your BBS, and your work's
    BBS/computer--giving yourself 2000:1/0 and the work computer 2000:1/1.
    You can exchange mail between your computers.  No big thing, just like
    being a Host/Hub of a (very) small network.  With this Destination
    Forwarding, however, you can have one computer forward any messages
    received on the other computer.  You could, for example, have your work
    poll your home computer for it's messages to-you it received last night,
    and have them ready for you to look over at work.

    The only real problem with this involves replying to these redirected
    messages.  The above scenario works fine--even works in reverse.  But
    replies become tricky, and I need to spend some time and trace out what
    exactly should happen and how with replies.  It is a dual problem, you
    see, the software has to properly reply and send it back to the first
    computer, in such a way that it is listed as un[Sent] so that it can be
    (again) mailed out to the Host/Hub for proper mailing.

    This also only works if the message first enters your BBS's message
    areas.  Pass-through messages that just go from the unpacking process to
    another mail bundle to another net address are not altered.


    Non-NET Message Giving

    When another BBS calls you directly to pick up messages, you can provide
    that sysop with the ability to pick up all messages to them in all
    areas--including the non-net mail areas, such as Private Mail.

    You do that in this database, which has merely the net address and
    sysop's name for fields.

    When the BBS corresponding to the net address calls, they are given all
    mail normally sent to their address, they will also be given any non-net
    mail messages corresponding to the name field.  It's usually sysop's
    name--but it need not be.

    This is not used much between strangers.  It does, however, make life
    easier for two sysops who leave each other lots of messages in lots of
    areas.  Instead of polling and calling to read mail, they need only
    poll.


    NameTags

    The NameTags database has only slightly to do with net mail.

    It contains 3 fields: the tag name, the user name, and the net address.

    This database provides a way for people (particularly the sysop) to
    enter a users name and (optionally) net address very quickly.

    Example:   JD    John Doe    1:154/900

    Then, when entering messages, at the "TO:" field I just type ".jd" and
    it fills in the name with "John Doe" and if its a NetMail area, the net
    address with "1:154/900".  Saving me the trouble of how to spell "John
    Doe", and the trouble of having to remember his net address.


    Import A Loose Fido PKT

    This option lets you import a loose Fido-style mail bundle.

    These bundles appear in two forms: with extensions of .PKT, and (when
    compressed) with extensions of .MOx, .TUx, .WEx, .THx, .FRx, .SAx, .SUx-
    -where "x" ranges from "0" to "9".

    These are what the software exchanges for mail exchange.  Under rare
    circumstances (such as running out of drive space) these files may not
    get processed.  That is what this command is for.

    This command can also be useful for those using other non-Fido-style
    networks to import converted-to-Fido-style mail bundles.


    Import An AREAS.BBS File

    This command is provided as a quick way for sysops who were using a
    front-end mailer before switching to this software.

    It will import the AREAS.BBS file and create the proper EchoMail
    Routing entries.

    It is very convient for Hubs, who often have to set up for many net
    addresses.


    SETUP: Menu Commands

    For the most part, net mail stuff is executed as events.

    The one exception is when you can do it by hand.  This is known as
    "immediate polling"--you call the BBS and ask them for your mail. Yes,
    it's just like calling and logging in and asking for mail.  However you
    are doing it using the net mail system--and some BBS's do not link net
    mail with login mail reading (for instance NetMail areas).

    This is done from <alt>d and Waiting-For-Caller.

    With <alt>d, you call them, hit <end>.  The software will ask you for
    the zone number of the BBS we called (or, if you don't know, use the
    one you use most).  Then it exchanges mail/etc. and hangs up.

    At the WFC screen, you hit F10, select "Crash Contact" and it will set
    up an immediate poll with whatever address you give it.  It retries
    every couple of minutes until contact is made.  This method requires
    that a nodelist entry for the address you're calling exist.

    Another non-command method to exchange mail is to do nothing.  You have
    them call you.  It's also the easiest.  This works for both single nodes
    calling for pick-up and Host/Hub's calling for pickup.

    Events are just an extension of this same theme, but do the dialing
    automatically.  Usually with net mail events you do make use of the "no
    later than" time field, and the "try every 5 minutes if busy" attribute.
    Quite often, the BBS you call will be busy, and certainly you do not
    want it trying to call forever--particularly if its a long distance
    call.

    There are a variety of net mail commands--all of which can be events
    (and <ctrl>Fx commands)--and they are listed below:

      First, a quicky overview of the unimportant commands.  Check the
      Command Helper in McEditor (or <alt>F3) for more help on these.

      -NET         Stop Inbound Net Mail
      +NET         Allow Inbound Net Mail
      -Usr         Stop People
      +Usr         Allow People
      DFRQ         Create a FREQ

      These are the important commands.  Additional information can be found
      in McEditor's on-line docs as well.

      ECHr         Direct EchoMail Processing     [ECHr _msgarea]

        This command will go through the EchoMail Routing database looking
        for addresses which are to receive this EchoMail area's mail.

        We then look into the Passwords & Attributes database.  For only
        those addresses who are to receive the EchoMail directly (have
        don't-route-via-hub ON) and are not up-to-date with the latest
        message in the area; we call and attempt to exchange net mail with
        them.

      NETr         Direct NetMail Processing      [NETr _msgarea]

        This command will go through the NetMail message areas looking for
        un[Sent] mail.

        We then look into the Passwords & Attributes database.  For only
        those addresses who are to receive NetMail directly (have don't-
        route-via-hub ON); we call and attempt to exchange net mail with
        them.

      NODa         Do Net Mail: Pre-Build     [NODa _phonenumber _netaddress]

        Example:  NODb _1-414-643-1576 _1000:1/1

        Pre-build packet, then call & exchange net mail.

        This command will first check to see if there is any mail to be sent
        to a net address.  If there is, we build our outbound mail bundle.

        We then call them, whether we have mail to drop off or not.

        Because we specify the net address here, we are forced to ignore any
        Alias net address's the BBS we call present us.

        Because we pre-build the bundle, you should only use this when you
        have a pretty good idea that the BBS you are calling is not likely
        to be busy.  Otherwise it has to pre-build the bundle again next
        time it calls.

      NODb         Do Net Mail: Pre-Build     [NODb _phonenumber _netaddress]

        Example:  NODb _1-414-643-1576 _1000:1/1

        Pre-build packet, then call & exchange net mail.

        This command will first check to see if there is any mail to be sent
        to a net address.  If there is, we build our outbound mail bundle,
        and then call them.  We do not call if there is nothing to send.

        This command is useful if you have lots of mail to send someone long
        distance--you do not want to waste any time building the packet
        after making connection.

        Because we specify the net address here, we are forced to ignore any
        Alias net address's the BBS we call present us.

        Because we pre-build the bundle, you should only use this when you
        have a pretty good idea that the BBS you are calling is not likely
        to be busy.  Otherwise it has to pre-build the bundle again next
        time it calls.

      NODd         Do Net Mail: Always        [NODd _phonenumber _zonenumber]

        Example:  NODd _1-414-643-1576 _1000

        This command will call the phone number and try to exchange mail
        with the BBS at the other end.

        This command is functionally equivalent to doing <end> in the <alt>d
        terminal program.

      NODm         Do Net Mail: If Mail For  [NODm _phonenumber _netaddress]

        Example:  NODm _1-414-643-1576 _1000:1/1

        This command will first check for outbound mail to an address.  If
        there is mail to send, then we call them and exchange mail.

      pBLD         Do Net Mail: Pre-Build/Wait            [pBLD _netaddress]

        Example:  pBLD _1000:1/1

        Pre-build packet, then do nothing.

        This command will first check to see if there is any mail to be sent
        to a net address.  If there is, we build our outbound mail bundle.

        Because we specify the net address here, we are forced to ignore any
        Alias net address's the BBS we call present us.

        This command is the traditional method of building mail bundles.  It
        minimizes phone call length, but maximizes hard drive use.

        After building the mail bundle, that net addresses information is
        updated just as if the bundle had been sent to them.  Thus, if the
        next night rolls around, and the bundle has not been picked up, we
        simply append any newer messages onto its end.

      Usually "NODa" is what you use to exchange mail with your Host/Hub.
      The rest are for various times when you send mail directly to other
      BBS's.


    DIRECTORY MANAGEMENT

    Like normal messages, file attaches to net mail messages are stored in
    the MSGSTUFF\<msgnum>.<area> format.

    The software stores outgoing net stuff in the MSGSTUFF\<zone>
    directories.

    Inbound files that are not attached to messages in a manner the software
    can perceive are stored in MISCMAIL\.  This includes inbound files that
    are not attached to any messages.

    For mail packets already existing in MSGSTUFF\<zone>, these are merged
    into our new packet and sent as a single packet (rather than multiple
    packets).

    The MSGSTUFF\<zone> directories can be ignored, and MISCMAIL should be
    checked for file attaches occasionally.

    For inbound and outbound stuff, TEMPAREA acts as a temporary holding
    area. Juggernaut will exit to DOS if it decides there isn't enough drive
    space to properly process your mail.  If this occurs, be sure to check
    the TEMPAREA for any files (such as inbound mail), and copy these to a
    safe area, restart the BBS, and then if TEMPAREA had mail, then choose
    the "import a loose packet" sysop command.


    MISC.

    One of the things the software does is zone matching.  It readjusts your
    list of addresses it provides to the other BBS in such a way as to put
    your addresses for their primary zone first.  The primary address is the
    first address of their (and your) address list, and is the one used for
    such things as password and attribute matching.

    This software also maintains a database of message ID's.  This provides
    defense against duplicate messages.  When you import messages, and you
    have logging of this ON, messages not imported because they were
    duplicates are noted with "(duplicate)" on their line.  Juggernaut
    maintains a library of ID information on the last 4000-6000 net
    messages.

    This software does not do "points".  Example: 1:154/42.2  Point nodes
    are invisible nodes, and you can duplicate the same functions by setting
    up a private network (with its own zone number) between the two
    computers.

    This software does not support "domains".  Example: 1:154/[e-mail]
    Domains are a bit confused right now--some are being used as a port into
    Internet, others are being used as an alternative to FidoNet to allow
    usage of zone 1 (and the other 1-10 zones) for a different network.  But
    mostly they're useless.

    When entering addresses within Juggernaut, you can use (for example) "1
    154 900", "1.154.900", etc.  You are not limited to the impossible-to-
    remember "x:y/z" format.

    Messages are given the date/time of when they arrive to the BBS--not the
    date/time when the message was created on another BBS.

    Message From-address (and sometimes To-address with replies) are gotten
    directly from inside the message itself via the MSGID fields.

    Important: only one node should be running net mail at one time.
    However, you may run net mail on multiple nodes provided they work with
    different zone's.

    The name problem:  If you send a netmail message to "name at x:y/z", and
    another user with the same name is already in your user list, then that
    user will be told of the message and able to delete it (unless you have
    the no-delete area flag ON).  Similarly, the same could happen if a new
    user log's in as "name".  Right now it's just a rare possibility.  But
    it is something I'll have to think of a solution for.  One solution:
    disallow login-users to read NetMail isn't something I consider a real
    solution (although a message area flag would be good).

    One thing you may not have noticed is that the software is always "in
    control" of the net addresses it uses when doing mail exchanges.  We
    define who gets EchoMail, we define what net addresses we call, we
    define who are our hubs, etc.  There is an important reason for this:
    you control who you call.  The only time this isn't true is with
    NetMail--and even then, for uncontrolled addresses you must route the
    mail via your hub. Control is necessary to keep Long Distance charges in
    control.  For instance, you must determine which BBS's to call Long
    Distance, and you must trust them.  Because there's nothing worse than
    setting up an event to dial a BBS long distance, and then in the morning
    discovering they didn't like you anymore and decided to dump a couple
    hours worth of files on you.  So the net system doesn't call anybody you
    don't let them to call.

    Messages greater than 16k: There is no way to create a message > 16k.
    For incoming messages, those that are > 16k will become file attaches in
    the NetMail area.  You can just move  them if they're EchoMail to the
    appropriate area.  Duplicate message checking on these messages is also
    not done.  The important thing to remember however: they are not lost,
    deleted, or split up.

    When reading messages with "show hidden lines ON", the the happy face in
    the MSGID line is a place holder--when the message is sent your net
    address will be put in that spot.  This provides flexible addressing,
    allowing the software to zone match your address into outbound messages,
    and to not have to redo all your messages should you change net addresses.

    If any one message within a mail .PKT bundle that is being imported into
    your message areas contains an ASCII character < 32 (space) in it's
    TO/FROM/SUBJECT fields, then the software assumes the whole packet is
    bad and moves it to MISCMAIL for you to look over.

    Also, if you hit <esc> during a packet import into your message areas,
    it will abort the process and move the file to MISCMAIL.


    SUMMARY OF OPERATIONS: NORMAL NODE

    You call another node and exchange mail.  If their address is your
    Host/Hub, they are given all outbound messages for that zone (excluding
    those to addresses marked "no route via Host/Hub").

    Any messages received that are not addressed to you are re-routed back
    to the the Host/Hub, or too their own mail bundle if they have "no route
    via Host/Hub".

    Thus, usually you won't have anything in MSGSTUFF\<zone>.  The exception
    is when returning mail not addressed to you--then you'll have a single
    file with the <netnode>.PKT or <netnode>.MO1 of your Host/Hub.


    SUMMARY OF OPERATIONS: HOST/HUB

    First, realize that the software works differently for your on-line
    messages, and for messages that are "passing-thru" you.

    The members of your net will upload bundles of messages addressed to
    you.  Only those addressed to you or your alias's are "processed".
    Those bundles not addressed to you are just placed into the outbound
    area, on the grounds that if the node knew enough to pack messages for a
    specific address, that they also knew enough to pack only messages to
    that address (very likely).

    Then the bundles to you are disassembled.  Any messages to you are
    imported into the message areas.  Any messages not to you are exported
    into your Region (the Region is defined using the Host/Hub entry--it's
    all the same principle but at a different level) bundle.  The exception
    is for "route directly" addresses, which may have their own bundle.

    So, as a Host/Hub, you are likely to have an on-going bundle in
    MSGSTUFF\<zone> addressed to your Region, as well as some on-going
    bundles addressed to nodes in your Net.

    When it comes time to do actual mailings, usually you will be giving
    bundles out.  However, if you are an Echo Coordinator, you may be giving
    out messages from your own BBS as well.  In that case, the bundles are
    merged and given to the other BBS.

    We then process our inbound bundle.  This operation is completely
    separate from the actual mail exchange.  We simple import any messages
    to us, and redirect any not to us to our Host/Hub bundle, or their own
    bundle if they are listed as "no route via hub".

    Thus, in the zones database you define your node address and that of
    your Region. Each night either you poll your Region or he polls you.

    For each node under your tutledge, you define an Passwords and
    Attributes entry for them to contain "don't route via hub" (otherwise
    it'll waste time and money sending their messages to the Region and
    back--and more importantly, it'll never create bundles of inbound mail
    for them).


    FUTURE

    More Internet support.  .TIC and AreaFix support.